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V  SUMMARY 

The  failure  analysis  strategy  described  in  these  notes  is  a 
diagnostic  method  for  increasing  the  assurance  that  the  root  cause  of 
a  problem  is  identified,  and  an  actual  case  study  which  illustrates 
the  failure  analysis  concepts,  is  included. 

The  use  of  the  special  diagnostic  methods  described  and  teams 
structures  are  an  effective  way  to  analyze  problems  that  are  par¬ 
ticularly  difficult  because  they  have  some  or  all  of  the  following 
characteristics: 

-  The  technical  problems  involve  several  divisions  or  functions, 
often  remotely  located  from  each  other. 

-  The  problems  are  so  technically  complex  that  no  one  is  com¬ 
pletely  sure  of  their  cause. 

-  Major  pieces  of  physical  evidence  were  destroyed  in  test  or 
are  on  inaccessible  test  ranges. 
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COURSE  DESCRIPTION 

Failure  Analysis  Seminar:  Techniques  and  Teams  (FASTT) 

Description  -  the  FAILURE  ANALYSIS  SEMINAR:  TECHNIQUES  AND  TEAMS 
(FASTT)  is  a  concentrated,  high-intensity,  three-day  (24  hours)  work- 
shop/seminar  designed  for  functional  engineers  and  mid-level  engineer¬ 
ing  management  personnel.  The  sessions  concentrate  on  identifying 
problem  areas  using  an  indepth,  structured  analysis  of  technical  and 
operational  problems.  In  a  broader  sense,  FASTT  is  a  diagnostic 
process  and  a  “way  of  thinking"  for  engineering  or  technical  personnel 
involved  in  the  design  and/or  operation  of  complex  systems.  Logic 
diagrams  and  root  cause  analysis  are  two  effective  methods  used  in 
this  course  for  confronting  technical  and  managerial  problems.  These 
techniques  are  particularly  productive  when  dealing  with  development 
failure  and  hardware  malfunctions  at  any  point  in  the  life  cycle  of 
a  product. 

The  course  also  focuses  on  the  dynamics  of  team  involvement  -  includ¬ 
ing  differences  in  perceptions  of  problem  areas,  communication  prob¬ 
lems  and  individual  differences.  Special  emphasis  will  be  given  to 
identifying  interpersonal  and  organizational  roadblocks  which  deter 
cooperative,  innovative,  and  competent  functioning  in  the  small  group 
environment. 

COURSE  OBJECTIVES: 

...  Techniques  for  a  systematic,  structured,  analysis,  and  solution 
of  a  broad  variety  of  technical  and  managerial  problems  by  indivi¬ 
duals  and  teams. 

...  Applying  analytical  techniques  to  “real  world"  problems. 

...  Awareness  of  group  dynamics  and  what  happens  among  and  to  team 
members. 

MAJOR  TOPICS: 


»  1 


-  Logic  diagrams  i 

-  Root  cause  analysis  process  j 

-  Failure  prevention  aids  q  1 

-  Design  reviews  _  1 

-  Idea  generation  techniques,  i.e.,  brainstorming,  morphology,  etc.  j 

-  Coaching  philosophy  j 

-  Management  in  the  failure  environment  -] 

-  Leadership  and  communication  skills  j 

-  Team  dynamics  and  organization  —  j 
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PREFACE 


The  introduction  of  sophisticated  and  highly  complex  consumer 
products  as  well  as  state  of  the  art  weapons  has  resulted  from  (and 
in  turn,  demanded)  extradorninary  advances  in  the  engineering  state 
of  the  art.  Unfortunately,  great  Increases  in  technical  sophistica¬ 
tion  have  not  been  matched  by  significant  advancement  in  the  ability 
to  deal  with  failures  of  this  complex  hardware. 

Many  diagnostic  tools  have  evolved  in  peicemeal  fashion  to  ad¬ 
dress  the  failure  of  specific  components  and  built-in  test  equipment 
is  included  in  many  mature  products  and  Increasingly  we  find  a  trend 
to  built-in  test  points  and  trouble  shooting  connectors.  However, 
the  design  of  methodologies  which  coordinate  the  flow  of  information 
concerning  a  failure  are  no  more  organized  than  the  design  of  the 
test  equipment.  The  conflicting  information  arising  from  the  crash 
of  a  DC-10  at  Chicago,  IL,  in  1979,  is  an  example  of  the  worst  kind 
in  failure  analysis,  and  press  release  analysis.  To  offset  the  prob¬ 
lems  of  the  past  and  to  provide  a  superior  technical  posture  during 
failure  situations,  the  diagnostic  process  described  in  the  seminar 
evolved. 

Each  consumer  product,  weapon  system  or  equipment  produced  and 
used  goes  through  a  life  cycle,  starting  with  concept  development  and 
concluding  with  the  completion  of  operational  life.  During  the  time 
interval  between  these  points  in  the  life  cycle  there  is  much  inter¬ 
facing  among  project  planners,  developers,  manufacturers,  support 
personnel,  test  and  evaluation  and  users,  often  worldwide.  Indeed, 
the  surfacing  or  problems  and  the  reporting  of  failures  throughout 
the  product  life  cycle  often  requires  a  unique  management  system  to 
plan,  guide  and  execute  the  activities  required  to  prevent  failures 
or  their  recurrence. 

In  principle,  many  organizations  have  policies  for  the  investi¬ 
gation  of  failures  and  many  organizations  have  detailed  record  keep¬ 
ing  functions  for  warranty  purposes.  However,  relatively  few  organi¬ 
zations  have  a  life  cycle  failure  analysis  and  control  function.  Be¬ 
cause  of  the  disparity  in  failure  emphasis,  it  is  important  that  the 
participants  be  aware  of  the  ned  for  a  formal  failure  prevention  and 
control  systems.  The  tailoring  of  a  failure  control  sytem  to  your 
organization's  needs  can  be  accomplished  by  using  the  seminar  content 
as  a  baseline. 
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FAILURE  ANALYSIS  SEMINAR: 


ORIENTATION 


PURPOSE  AND  OBJECTIVES 

-  To  acquaint  participants  with  methods  for  gathering  and  or¬ 
ganizing  data  related  to  failure  situations  by  individuals 
and  small  teams. 

-  To  identify  the  thrust  of  technical  strategies  aimed  at  pre¬ 
venting  failure  including  design  reviews,  data  base  develop¬ 
ment,  and  periodic  reporting. 

-  To  demonstrate  the  effectiveness  of  team  problem  solving. 

Key  topics  which  support  these  objectives  include  Logic  Dia¬ 
grams,  Root  Cause  Analysis,  Generation  of  Failure  Scenarios, 
Team  Dynamics  and  Small  Group  Processes,  and  Failure  Preven¬ 
tion  Strategies.  Workshops  to  Illustrate  these  topics  will 
encompass  more  than  half  the  seminar  schedule. 

SEMINAR  OUTLINE 

The  simlnar  outline  indentifies  discrete  and  significant  items 
of  information.  These  serve  as  baselines  from  which  the  instructor 
builds  on  the  processes  and  content. 

Within  the  allocated  times,  the  instructor  will  exercise  judge¬ 
ment  in  how  detailed  each  topic  will  be.  The  course  outline  is  in¬ 
tended  to  provide  for  presentation  flexibility  and  each  segment  of 
the  outline  is  an  aid  toward  achieving  the  learning  objectives. 

REFERENCE  MATERIAL 

Reference  material  included  or  noted  in  the  text  complements 
the  seminar  outline  by  providing  supporting  materials  and  case  studies. 
References  Included  in  the  text  represent  key  policy  considered  most 
pertinent  to  the  seminar. 

Failure  analysis  methods  are  dynamic  and  growing.  Frequent 
improvements  are  expected  as  new  methodologies  for  specific  techno¬ 
logies  are  evolved.  The  loose-leaf  format  allows  each  participant 
to  tailor  the  reference  material  to  their  specific  discipline. 


ORIENTATION 


I.  ADMINISTRATIVE  MATTERS/OPENING  AND  REGISTRATION 

A.  Seminar  Organization  and  Procedure 
Learning  Objectives 

(1)  To  identify  seminar  purpose  and  objectives  and  to  high¬ 
light  elements  of  seminar  content  and  presentation  media. 

(2)  To  identify  and  relate  product  availability,  product 
assurance  and  design  problems  to  seminar  content. 

(3)  To  introduce  techniques  for  the  definition,  analysis, 
and  solution  of  problems  by  individuals  and  teams. 

(A)  To  develop  competence  in  applying  analytic  techniques 
to  "real  world"  problems. 

(5)  To  create  an  awareness  of  group  process  -  what  happens 
between  and  to  group  members. 

B.  FASTT  Seminar 
Primary  Purposes 

(1)  Provide  an  understanding  of  key  problem-solving  concept 
and  a  policy  for  acquiring  effective  armament  material,  and 
illustrate  a  methodology  for  the  analysis  of  problems. 

(2)  Reflect  requirements  for  participants'  application. 

(3)  Learner  centered  approach  to  training  lecture  supported 
material . 


(a)  Review  seminar  materials 

(b)  Learning  reinforcement  techniques 

(c)  Instructor  and  participants'  roles 


c.  Topical  Approach  to  Subject  Matter 
(l)  Introduction  and  Orientation 


(2) 

Team  Operations  Simulation 

*  1 

\  1 

(3) 

General  Concepts 

(4) 

Logic  Diagrams 

%  ‘ 

-  Workshop 

(5) 

Root  Cause  Analysis 

-  Workshop 

(6) 

Alternative  Scenarios  Evolution 

•  ' 

(7) 

Case  Study 

-  Workshop 

(8) 

Coaching  Philosophy 

-  Workshop 

9 

(9) 

Failure  Prevention 

(10) 

Recap  and  Close  Out 

Instructor  and  Participant  Roles 

9 

(1) 

Instructor' 8  Role 

>  ‘ 

-  Transmit  Information 

-  Generate  Discussion 

•y  ' 

-  Debrief  Activities 

9' 

(2) 

Participant's  Role 

-  Get  Involved 

-  Use  Time  Effectively 

-  Feedback  Problems  and  Progress 

• 

-  Evaluate 

-f* 
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FAILURE  ANALYSIS  STRATEGY1 
Augustine  E.  Magistro 


Introduction 

A  primary  task  of  management  and  systems  engineers  is  to  establish 
the  normal  performance  limits  for  an  item,  recognize  abnormal  performance 
or  failure,  determine  the  cause  of  failure,  and  derive  effective  solutions. 

The  determination  of  the  cause  of  failure  is  often  the  most  formid- 
ible  task  presented  to  engineers  during  the  development  of  an  item.  In 
the  early  phases  of  a  major  tactical  missile  system,  the  Government  agencies 
and  contractors  involved  were  very  effective  at  quickly  applying  "fixes" 
to  failures.  In  many  cases,  the  apparent  problem  was  treated,  but  often 
the  same  failure  recurred.  Significant  costs  in  dollars,  time  and  anxiety 
were  suffered  by  several  levels  of  management  each  time  the  corrective 
action  was  inadequate.  Therefore,  it  became  evident  that  a  technique 
was  required  which  assured  that  the  root  cause  of  a  failure  was  detected 
and  removed.  In  this  atmosphere  a  series  of  innovations  evolved  which 
produced  a  failure  analysis  strategy  which  combined  elements  in  a  new  way. 

The  failure  analysis  strategy  assures  that  activities  conducted  to 
assess  the  basic  or  root  cause  of  failures  are  adequate  in  scope,  and  are 
capable  of  identifying  a' I  the  likely  conditions  which  may  have  contributed 
to  the  problem.  Data  gaps  and  completeness  of  activities  are  a  major  focus. 


This  article  contains  portions  of  material  originally  published  as 
part  of  U.  S.  Army  Missile  Command  Technical  Report,  Number  RF-75-2 
"Root  Cause  Analysis  -  A  Diagnostic  Failure  Analysis  Technique  for 
Managers,"  26  March,  1975,  by  Augustine  Magistro,  Picatinny  Arsenal  and 
Lawrence  R.  Seggel,  U.  S.  Army  Missile  Command.  The  report  is  available 
from  the  National  Technical  Information  Service,  5285  Port  Royal  Road, 
Springfield,  Va.  22151. 
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Failure  Analysis  Strategy 

Generally  aost  problems  surface  with  the  occurence  of  an  ap¬ 
parent  failure  or  deviation  in  performance  and  the  first  major 
activity  in  technical  problem  solving  is  to  arrive  at  a  statement 
of  the  problem  which  provides  maximum  visibility  to  the  possible 
failure  causes.  An  Initial  statment  of  the  problem  is  evolved  and 
the  symptoms  are  described  in  terms  of  what  happened  and  what  were 
the  events  leading  to  the  problem. 

A  typical  problem  statement  is;  "the  car  won't  start.  No  sound 
heard  when  key  is  operated.”  In  this  case,  the  driver  is  the  problem 
solver  and  must  collect  additional  information  in  order  to  proceed. 
The  driver  is  faced  with  a  "mess”  and  since  little  Information  is 
available  the  driver  must  collect  and  organize  new  information  about 
the  problem.  Figure  1  is  a  model  of  the  process.  First,  the  driver 
thinks  about  systems  which  could  be  involved  and  selects  from  among 
them  the  system  which  is  likely  to  be  involved.  Next,  the  driver 
specified  what  subsystems  could  be  involved  and  speculated  that  the 
battery,  starter  and  solenoid  were  likely  areas  of  investigation. 

The  driver  then  considered  components  of  the  subsystems  such  as 
cables  changes  and  mounting  hardware  for  the  starter.  The  hierarchy 
of  the  drivers  analysis  is  depicted  in  figure  I  proceeds  from  general 
to  specific  areas,  and  when  completed  will  display  all  the  parts 
which  may  be  involved  in  the  problem.  At  the  component  level  we  have 
a  "bite  size"  piece  of  the  problem  to  investigate. 

The  driver  would  continue  the  analysis  until  a  specific  replace¬ 
able  part  was  identified  and  replaced.  The  driver's  problem  solving 
would  stop  when  the  car  was  started,  however,  the  auto  designer  is 
interested  in  isolating  the  causes  of  the  problem.  Thus  the  auto 
designer  would  continue  the  hierachial  model  evolution  beyond  the 
model  of  figure  1  to  further  isolate  piece  part  failures.  The  auto 
designers  objective  is  to  establish  the  failure  mode  of  the  piece 
part  and  to  prevent  recurrence  of  component  failure.  Tour  role  in 
the  seminar  is  to  act  as  the  system  designer. 


PROBLEM  SOLVING  STRATEGY 


Logic  Diagram  Background 

Fault  Tree  Logic  Analysis  was  initially  developed  in  1962  by 
Bell  Telephone  Laboratories  in  connection  with  the  Air  Force's  Minute- 
man  Missile  System.  Specifically,  it  was  utilized  to  predict  what 
combination  of  events  and  circumstances  could  cause  an  undesired 
event  such  as  an  unauthorized  missile  launch.  Recently  application 
of  this  technique  was  made  to  diagnostic  failure  analysis.  This  has 
been  caused  in  part  by  the  increased  emphasis  on  new  methods  and  tech¬ 
niques  to  improve  the  response  time  to  the  analysis  system  failures. 

The  logic  diagram  provides  a  convenient  visual  "roadmap"  of  the 
problem.  It  permits  the  problem  solver  to  diverge  and  helps  to  eli¬ 
minate  tunnel  vision. 

Fault  Tree  Logic  Diagrams 

Fault  logic  is  a  pictorial  representation  of  the  various  paral¬ 
lel  and  series  combinations  of  subsystem  and  component  failures  which 
can  result  in  a  specified  system  failure  (see  Figure  2^.  The 

fault  logic,  when  fully  developed,  may  be  mathematically  evaluated  to 
establish  the  probability  of  occurrence  of  the  ultimate  undesired 
event,-  as  a  function  of  the  estimated  probabilities  of  occurrence  of 
identifiable  contributory  events.  However,  in  many  diagnostic  studies 
quantification  is  not  possible  since  failure  rate  data  is  not  avail¬ 
able.  Only  unquantified  fault  logic  diagrams  are  described  in  this 
section.  The  logic  diagram  examples  shown  are  simplified  but  serve 
to  show  the  event  relationship  to  the  effects. 

Fault  Logic  Construction 

Development  of  a  fault  logic  begins  with  the  definition  of  the 
end  system  fault  condition  ("undesired  event”).  The  system  is  then 
analyzed  and  all  the  logical  combinations  of  function  fault  events 
which  can  cause  the  undesired  event  are  postulated.  Such  an  analysis 
is  dependent  upon  a  thorough  knowledge  of  the  system  functions  and 
equipment  and  an  individual  willing  to  explore  many  alternate  failure 
scenarios.  Each  of  the  contributory  fualt  events  is  further  analyzed 
to  determine  the  logical  interrelationships  of  system  fault  events 
which  can  cause  them.  Analysis  if  facilitated  if  the  fault  events 
are  systematically  classified  according  to  failure  cause.  In  this 
mannter  a  thee  of  logical  relationships  among  fault  events  is  devel¬ 
oped.  The  development  is  continued  until  all  relevant  fault  events 
on  for  the  problem  are  defined  in  terms  of  basic,  identifiable 
faults. 


A  summary  of  the  steps  for  fault  logic  diagram  construction 
follows: 

1.  Carefully  analyze  the  system  or  component.  Determine  tlu* 
sequence  of  events  for  normal  operation,  normal  and  abnormal  operating 
environments  and  safety  implications. 

2.  Specify  the  undesired  event  of  the  fault  logic  diagram.  This 
may  be  failure  of  the  total  system,  property  damage,  human  injury,  or 
any  other  event  that  might  result  in  not  satisfying  requirements. 

3.  Initiate  actual  construction  of  the  fault  logic  diagram. 
Determine,  in  a  logical  manner,  the  events  that  can  cause  the  unde¬ 
sired  effect. 

4.  Establish  what  major  systems  could  be  involved. 

3.  Determine  what  major  components  in  the  system  could  be 
involved. 

6.  Speculate  how  the  component  could  fail. 

7 .  Determine  which  parts  of  the  major  components  could  cause 
the  component  of  fall  (Note:  A  functional  construction  related  to 
components  is  perf erred  since  it  relates  conveniently  to  part 
numbers) . 

8.  Display  this  Process  graphically. 

9.  All  the  logic  events  are  given  reference  numbers  in  order 
to  cross  reference  the  basic  fault  event  to  other  charts.  Figures 
II  through  IV  depict  the  construction  order  for  an  electrical  system 
problem. 

10.  After  the  construction  of  the  logic  diagram  is  completed, 
each  entry  is  evaluated.  Diagonal  lines  are  drawn  thru  events  not 
considered  likely  to  be  involved  and  a  circle  is  placed  adjacent  to 
likely  causes.  Most  likely  causes  may  also  be  designated  by 
combinations  of  symbols.  Figure  2  describes  this  process. 
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FIGURE  2  -  LOGIC  DIAGRAM  CONSTRUCTION 
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Root  Cause  Anlaysis  Format 

Subsequent  to  the  development  of  the  logic  diagrams,  failure 
sequences  are  postulated  and  information  which  either  refutes  the 
sequence  or  supports  it  is  assembled  on  standard  columnar  format, 
shown  in  Figure  2k  It  is  a  simple  one,  however,  it  must  be  conscien¬ 
tiously  completed  and  updated  to  be  effective.  The  presentation  of 
information  in  the  format  of  Figure  3  allows  each  failure  sequence 
and  its  supporting  rationale  to  be  quickly  reviewed. 

The  root  cause  analysis  chart  is  executed  as  follows: 

Failure  Indication  -  A  simplified  statement  of  the  observed  failure 
and  its  symptoms  are  entered. 

Cause  Probability  Estimate  -  The  assignment  of  the  failure  mode 
cause  probability  estimate  should  be  stated  in  terms  of  "not  cause, 
probable  contributor,"  "unlikely  cause,  likely  cause"  and  “root 
cause."  The  probability  estimate  is  useful  in  ranking  failure  modes. 

Failure  Mode  -  A  potential  failure  mode  from  the  logic  diagram  li6t  is 
entered,  one  to  a  page.  Pages  are  added  as  additional  modes  are  evolved. 

Failure  Sequence  -  the  failure  mechanism  of  the  postulated  failure 
mode  is  briefly  described,  for  each  failure  mode  entered,  and  only 
one  sequence  is  entered  per  page.  Describe  what  is  speculated  to 
have  happened,  when  it  occured,  who  was  involved,  where  on  the  part, 
how  it  is  manifested,  and  why  it  failed. 

Supporting  Data  -  Actual  test  data,  “facts"  and  substantiated  analyses 
that  are  established  from  detailed  investigation  of  the  failure  mode 
are  listed.  Facts  that  support  the  failure  mode  and  failure  sequence 
are  briefly  listed  in  just  enough  detail  to  be  understood  by  the  team. 

Refuting  data  -  All  facts  established  during  the  detailed  analysis 
of  all  data  that  refute  the  postulated  failure  mode  and  failure  se¬ 
quence  are  entered  concisely. 

Additional  data  and  tests  required  -  List  required  investigations  to¬ 
gether  with  their  estimated  completion  date  in  this  column.  As  the  in¬ 
vestigation  proceeds  it  will  become  clear  that  there  are  gaps  in  the 
analysis  or  data  available.  This  additional  Information  would  provide 
a  basis  determining  whether  the  postulated  failure  mode  is  or  is  not 
the  cause  of  the  observed  failure. 

Corrective  Action  -  Any  corrective  actions  required  should  be  Indicated 
and  the  appropriate  block  checked.  Interim  actions  or  adaptive  actions 
should  also  be  entered  in  this  area.  Figure  ^thru  6  illustrate 
these  steps.  ' 

The  root  cause  analysis  charts  are  "living”  documents  and  when 
additional  data  are  made  available,  prior  entries  are  deleted  and  the 
results  entered  in  either  the  supporting  or  refuting  data  columns. 

2 

For  description  of  Red  Teams,  see  Volume  3. 
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D*u  a*v  No  ROOT  cause  analysis  chart 

PoOvro  Indication  ENTER  BRIEF  STATEMENT  OF  Caua  ProbabOitr  Ectanatai  USED  DURING  EARLY 

FAILURE  INDICATION  STAGES  TO  INDICATE  CAUSE  PROBABILITY 

WHEN  LITTLE  IS  KNOWN  ABOUT  THE  FAILURE 
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FIGURE  3  -  ROOT  CAUSE  ANALYSIS  CHART  INSTRUCTION  FORMAT 


FIGURE  4  -  SAMPLE  ROOT  CAUSE  ANALYSIS  CHART 

FAILURE  INDICATION:  BECO  AT  ENGINE  IGNITION  CAUSE  PROBABILITY  ESTIMATE  POSSIBLE 


SPECULATION 

FAILURE  MODE _ 

Instrumentation. 

FAILURE  SEQUENCE 

Inscru.  short  causes 
saturation  oh  integ 
or  \ .A.  or  causes 
power  battery  drain. 


EVALUATION 

SUPPORTING  DATA 

REFUTING  DATA 

ADD'L  DATA 
TESTS  Rt.Q'D 

None, 

TM  records  all  show 
normal  functioning 
with  no  evidence  of 
short;  all  TM 
monitoring  points 
are  current 

1 iml ted . 

B  H  checkout 
at  LTV  AC -We 

CAUSE  PROBABILITY  ESTIMATE:  UNLIKELY 


EVALUATION 

SUPPORTING  DATA 

REFUTING  DATA 

ADD’L  DATA 
TESTS  REQ’f 

None. 

Functional  check¬ 
out  of  power 
switch  at  LTVAC-M 
no  avldenca  of 
pulae  battery 
drain  at  activa¬ 
tion  on  TM 
records. 

None. 

FIGURE  5  -  SAMPLE  ROOT  CAUSE  ANALYSIS  CHART 

ROOT  CAUSE  ANALYSIS  CHART 

FAILURE  INDICATION:  8 ECO  AT  ENCINE  IGNITION  CAUSE  PR0BABILIT 

SPECULATION  ’ _ EVALUATI0W 

FAILURE  MODE  _  SUPPORTING  DATA  REFUTING  M 

Nona.  Functional  c 

Shorted  VCE  power  out  of  poB.r 

SWitCh.  ..  ir 


FAILURE  SEQUENCE 

Shorted  transistor 
flras  BTV  at  pulse 
battery  activa¬ 
tion. _ 


FIGURE  6  -  SAMPLE  ROOT  CAUSE  ANALYSIS  CHART 

FAILURE  INDICATION:  REOO  AT  ENGINE  1  .NIT ION  CAUSE  PROBABILITY  ESTIMATE:  UNLIKELY 

SPECULATION  EVALUATION 

f  ADD'l  DATA 

FAILURE  MODE  SUPPORTING  DATA  REFUTING  DATA  TESTS  REQ'D 

Failed  VCE  None.  TM  records  show  no  None. 

saturation,  no  BGG, 

;  "  and  a  austalner 

FAILURE  SEQUENCE  full.on  (tgn.1; 

VCE  checked  OK  on 

Positive  saturation  CfcC  SAB  and  test 

of  V.A.  or  negative  console, 

saturation  of  Integ 

triggers  BTV,  -  . .  . — 

giving  BGG  signal 
and  driving  the 
austalner  full-on. 


The  root  cause  analysis  chart  format  fulfills  several  signifi¬ 
cant  purposes: 

-  Provides  a  prompt  overview  of  the  status  at  any  point  during 
the  failure  analysis  process.  This  is  valuable  to  the  team  and  to 
management . 

-  Describes  and  plans  follow-on  activity  required  to  complete 
the  analysis. 

-  Provides  an  auditable  review  record  in  the  simplest  terms 
which  allows  independent  assessment  by  disinterested  parties  such  as 
"red  teams”^  and  "blue  ribbon  panels." 

-  Concisely  presents  the  balance  between  confirming  and  refuting 
data  upon  which  determinations  are  based. 

-  When  the  root  cause  is  identified,  the  information  on  the 
format  explicitly  describes  the  failure  process  and  demonstrates 
that  other  causes  are  eliminated  from  contention. 

This  technique  requires  discipline  to  produce  solutions.  It 
takes  patience  and  discipline  at  all  levels  of  management  to  allow 
the  analysis  team  to  do  the  thorough  diagnostic  job  that  is  required. 

Logic  Diagram  and  Root  Cause  Analysis  Relationship 

The  logic  diagrams  and  the  root  cause  analysis  columnar  format 
supplement  each  other.  The  logic  diagram  provides  a  road  map  to  guide 
the  problem  solver  to  each  postulated  cause  of  failure  and  the  root 
cause  analysis  chart  presents  a  scenario  for  each  of  the  failures. 

All  the  data  required  to  reach  a  conclusion  concerning  the  likeli¬ 
hood  of  the  scenario  is  presented  in  the  format.  Each  event  of  the 
logic  diagram  is  numbered  and  the  event  numbers  are  entered  in  the 
failure  mode  columns  and  thus  the  root  cause  analysis  chart  and  logic 
diagram  are  cross  referenced.  Figures  7  and  8  illustrate  this  rela¬ 
tionship. 


LOGIC  DIAGRAM 


ANALYSIS  CHART  RELATIONSHIP 
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1  8  -  BREECH  LOGIC/ROOT 
ANALYSIS  CHART  RELATIONSHIP 


FIGURE  9 

FAILURE  ANALYSIS  CHRONOLOGY 

♦♦♦PROBLEM  SURFACES 
♦♦♦PROBLEM  STATEMENT 

♦♦♦MANAGEMENT  DECISION  -  "ROOT  CAUSE"  REQUIRED 

♦♦♦DIAGNOSTIC  TEAM  FORMALLY  ESTABLISHED 

♦♦♦POSTULATE  FAILURE  MODES 

♦♦♦LOGIC  TREE  OF  FAILURE  MODES 

♦♦♦ALL  CREDIBLE  FAILURE  MODES  ESTABLISHED 

♦♦♦RANK  ITEMS  ON  LOGIC  DIAGRAM 

*** INITIATE  FAILURE  MODE  AND  SEQUENCE  OF  ROOT 
CAUSE  FORMAT  -  ONE  PER  SHEET 

♦♦♦SPECIFY  ADDITIONAL  DATA  OR  TESTS  REQUIRED 

♦♦♦OBTAIN  DATA  CONFIRMING/REFUTING  EACH  MODE 

♦♦♦ANALYSIS  OF  DATA 

♦♦♦CATEGORIZE:  MOST  LIKELY/LIKELY/NOT  LIKELY 
♦♦♦REDEFINE  PROBLEM 
♦♦♦CONCENTRATE  ON  MOST  CREDIBLE 
♦♦♦SPECIFY  FAILURE  MECHANISM  OF  MOST  LIKELY  CAUSE 
♦♦♦DUPLICATE  FAILURE  CAUSE 
♦♦♦"ROOT  CAUSE"  ESTABLISHED 
*** IMPLEMENT  CORRECTIVE  ACTION 
♦♦♦LESSONS  LEARNED 
♦♦♦DEBRIEF/AUDIT 
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Importance  of  Verifying  Facts 

The  first  major  activity  in  problem-solving  is  to  arrive  at  a 
valid  statement  of  the  problem.  All  input  data  should  be  challenged; 
it  is  paramount  for  a  manager  or  investigator  to  know  the  difference 
between  the  facts  available  and  the  assumptions. 

It  is  essential  that  only  established  facts  be  entered  In  the 
supporting  and  refuting  data  columns.  There  is  no  allowance  for 
supposition  beyond  the  failure  mode.  The  failure  sequence  column, 
together  with  the  facts  established  and  listed  in  the  supporting  and 
refuting  data  columns,  will  determine  which  failure  modes  are  not  the 
cause,  which  are  potential  contributors  to  the  failure,  and  which  one 
is  the  most  probable  root  cause. 

Some  of  the  data  will  be  available  within  moments  of  the  failure, 
while  other  data  may  take  weeks  to  assemble  or  develop.  The  data 
that  are  available  within  the  first  two  to  three  days  after  the 
incident  forms  a  basis  upon  which  the  root  cause  investigation  is 
initiated.  The  remainder  of  the  data  become  useful  to  refute  or 
support  particular  failure  modes.  In  some  cases,  new  data  might 
suggest  previously  unidentified  failure  modes.  The  following  is  a 
listing  of  some  of  the  key  sources  of  data: 


Test  Data 
Telemetry  Data 
Preliminary  Test  Reports 
Environmental  Test  Results 
Compatibility  Tests 
Preflight  Test  Results 
Manufacturing  Records 
Assembly  Instructions 
Failure  History  Data  Banks 


Inspection  Data 
Quality  Assurance  Data 
Reject  Reports 
Waivers  and  Deviations 
Critical  Component  Data 
Laboratory  Simulations 
Previous  Test  Reports 
Historical  Failure  Summaries 


Although  the  preceeding  list  is  not  all  inclusive,  it  serves  to 
show  that  there  are  many  sources  of  applicable  data  that  may  provide 
insights  and  facts. 


Use  verified  data  from  all  available  sources.  Take  steps  to 
verify  all  data  used  as  rapidly  as  possible.  Be  sure  to  identify 
assumptions  and  unverified  data  as  such,  so  that  they  do  not  become 
confused  with  facts.  Do  not  discard  data  as  invalid  without  proving 
that  the  data  are  incorrect. 
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Root  Cause  Organization 

Figure  9  presents  a  typical  block  diagram  of  an  ad  hoc  root 
cause  analysis  organization.  The  ad  hoc  team  approach  is  shown  be¬ 
cause  it  represents  an  organization  appropriate  for  the  investigation 
of  the  most  difficult  types  if  failures,  (those  where  the  data  base 
is  small,  the  known  facts  are  few,  the  areas  of  possibility  are  many, 
and  the  time  to  reach  a  total  understanding  is  expected  to  be  more 
than  several  weeks).  After  the  initial  failure  modes  are  listed  on 
the  root  cause  analysis  chart  and  the  initial  failure  data  reviewed, 
it  is  generally  apparent  what  type  and  magnitude  of  organization  is 
necessary.  Simplifications  of  this  basic  organization  are  obvious. 

When  a  problem  is  of  such  magnitude  as  a  required  long-term  in¬ 
volvement  of  personnel  from  several  major  organizations,  it  is  bene¬ 
ficial  to  have  an  understanding  at  the  highest  levels  of  those  organ¬ 
izations.  This  assures  that  the  support  required  will  be  the  type 
and  quality  needed  and  will  be  continuous.  In  the  Government,  sep¬ 
arate  commands  and  agencies  as  well  as  contractors  and  institutional 
consultants  may  be  involved.  Similar  situations  arise  within  indus¬ 
trial  concerns.  A  charter  delineating  responsibilities  of  each  in¬ 
dividual  or.  the  team  and  especially  the  leader  is  a  must;  this  charter 
must  be  agreed  to  by  all  organizations  represented  for  an  effective 
and  efficient  analysis. 

-  A  brief  statement  of  the  problem. 

-  A  statement  of  the  significance  of  the  problem. 

-  Designation  of  the  root  cause  team  leader. 

-  Designation  of  the  site  of  the  team's  operations. 

-  Definition  of  the  support  required  of  each  supporting  organi¬ 
zation;  names  of  specific  individuals,  if  practicable. 

-  Best  estimate  of  the  duration  of  the  investigation. 

The  root  cause  team  leader  is  the  hub  of  the  analysis.  The 
team  leader  should  possess  the  qualities  of  the  top  manager,  l.e., 
an  organized  and  disciplined  individual.  Technical  skills  are  a 
secondary  consideration. 

The  root  cause  team  leader  performs  the  following  functions: 

-  Directs  and  controls  the  activities  of  the  team. 

-  Prepares  the  ad  hoc  team  charter  if  required. 


ft 


ft 


ft 


ft 
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-  Arranges  for  he  team  staffing. 

-  Describes  the  root  cause  analysis  technique. 

-  Establishes  task  teams. 

-  Distributes  root  cause  analysis  charts  to  task  teams. 

-  Presents  established  facts  describing  the  problem. 

-  Assists  in  listing  "failure  modes." 

-  Completes  "failure  sequence"  on  root  cause  analysis  charts. 

-  Develops  follow-on  activities  test  and  analysis  requirements 

with  due  dates. 

# 

-  Obtains  support  of  technical  specialists  as  necessary. 

-  Provides  data  outputs  and  findings  to  root  cause  team  leader 
and  other  task  teams. 

-  Iteratively  update  root  cause  analysis  charts  and  assist  in 
assigning  cause  probability  estimates  for  each  failure  mode. 

-  Assures  that  assignment  due  dates  are  met. 

-  Prepared  cost  estimates  and  authorizations  for  management  as 
required. 

-  Arranges  for  "red  team"  or  "blue  ribbon  panel”  reviews  if  the 
problem  warrants  that  magnitude  of  independent  review. 

Each  team  should  have  an  executive  secretary  who: 

-  Prepares  listing  of  participants  with  addresses  and  phone 
numbers . 

-  Arranges  meetings. 

-  Distributes  minutes,  reports,  and  data  to  the  team  members. 

-  Prepares  and  updates  the  root  cause  analysis  chart. 

-  Maintains  a  chronological  file  of  all  material  to  serve  as  a 
reference  information  bank  and  allows  the  various  task  teams  to  ac¬ 
quire  data  without  slowing  up  other  teams.  This  can  be  very  impor¬ 
tant  because  the  regular  cross  feeding  of  information  among  the  task 
teams  speeds  up  the  analysis  process. 
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-  Summarizes  the  findings  of  the  various  task  teams  and  issues 
interim  data  to  the  teams. 

-  Prepares  visual  aids  for  briefings,  conferences,  etc. 

-  Directs  the  preparation  of  the  final  report  of  root  cause. 

The  executive  secretary  may  require  secretarial  support  as  a 
minimum  and  additional  support  will  be  dependent  upon  the  magnitude 
of  the  problem  under  study  and  the  size  of  the  group.  The  organiza¬ 
tion  and  supporting  staff  should  be  kept  to  the  minimum  because  ft 

larger  groups  are  .unwieldy  and  costly.  There  is  no  substitute  for 
good  judgement  in  this  area. 

The  task  teams  consist  of  one  to  five  individuals,  with  a  given 
area  of  expertise.  It  is  their  function  to  evaluate  the  available 
data  and  develop  supporting  and  refuting  data  for  the  root  cause 
analysis  chart  on  those  failure  modes  that  are  within  their  area  of 
expertise.  The  task  teams  will  also  determine  what  additional  data 
are  required  to  resolve  each  failure  mode.  They  should  write  indivi¬ 
dual  fact  sheet  reports  on  their  findings.  Dissemination  of  informa¬ 
tion  findings  among  task  teams  and  to  the  root  cause  team  leader  on 
a  timely  basis  cannot  be  overemphasized.  The  crossfeeding  of  informa-  * 

tion  allows  for  maximum  progress  and  minimizes  duplicative  effort. 

Initial  internal  independent  reviews  can  often  be  provided  by  other 
task  teams  and  serve  as  an  initial  critique  of  the  validity  of  the 
findings  and  conclusions  drawn.  In  this  way,  perspective  is  gained. 

The  task  teams  may  add  to  the  failure  modes  list  as  the  investi-  » 

gat  ion  provides  new  insights.  Failure  modes,  once  stated,  cannot  be 
arbitrarily  deleted. 

Technical  specialist  support  of  the  activities  may  be  necessary 
to  perform  specific  analyses  or  tests.  This  is  required  to  assure 
that  the  task  team's  time  and  talents  are  effectively  used  or  to  • 

provide  skills  not  present  on  the  task  team  itself. 

Root  Cause  Analysis  Cycle 

The  root  cause  analysis  process  initially  emphasizes  problem 
analysis  activities  and  does  not  consider  corrective  actions  or  9 

"fixes"  until  at  least  a  postulated  cause  has  been  identified.  The 
process  predicts  failure  scenarios  and  either  eliminates  them  from 
contention  or  elevates  them  to  the  level  of  likely  causes,  via  the 
assembly  of  relevant  information.  In  general,  the  process  does  not 
consider  solution  until  likely  causes  are  explicitly  identified  and 
failure  mechanism  duplicated.  m  ' 
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A1  t-prnat  ius  Evolution  -  The  ability  to  structure  the  logic  diagrams 
«nd  the  speculation  section  of  the  Root  Cause  Analysis  Chart  is 
enhanced  by  the  generation  of  alternatives.  The  more  alternatives 
considered  the  less  chance  of  omitting  a  cause  of  a  problem. 

ALTERNATIVES 

In  all  problem-solving  situations  there  will  be  a  number  of 
alternatives  that  can  be  identified.  Often  we  do  not  search  for 
alternatives  and  so  they  are  not  as  "apparent"  as  they  could  be  if 
we  would  only  look.  To  be  creative  problem-solvers,  you  will  have  to 
think  of  as  many  possible  alternatives  as  you  can  for  our  objective 
to  be  accomplished.  Do  not  at  this  point  assess  the  value  of  any 
potential  solution. . .just  list  it  as  a  possibility.  The  deferring  of 
the  value  of  an  idea  is  a  key  concept  in  evolving  many  ideas. 

At  this  point,  concentrate  on  making  sure  you  are  considering 
all  possibilities.  Only  after  you  have  all  possible  solutions 
listed  should  you  begin  to  evaluate  each  of  their  potentials  and 
feasibi 1 i ty. 

There  are  numerous  techniques  to  increase  your  ideation 
potential  --  brainstorming,  morphology,  metaphors,  bionics,  etc. 

Basic  to  all  of  these  techniques  is  deferring  judgement  -  not  prejudging 
or  inferring  it  "won't  work."  (See  Osborn's  "Rules  of  Brainstorming" 
and  "Checkl ist.") 
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OSBORN’S  RULES  FOR  BRAINSTORMING: 


1.  CRITICISM  IS  RULED  OUT  -  Judgement  Is  suspended  until  a  later 
screeing  or  evaluation  session.  Allowing  yourself  to  be  critical 
at  the  same  time  you  are  being  creative  is  like  trying  to  get  hot 
and  cold  water  from  one  faucet  at  the  same  time.  Results  are  luke- 


2.  FREE-WHEELING  IS  WELCOME  -  The  wilder  the  ideas,  the  better. 
Off-beat,  inpractical  suggestions  may  trigger  in  another  participant 
ideas  which  might  not  have  occured  to  them. 

3.  QUANTITY  IS  WANTED  -  The  greater  the  number  of  ideas,  the  greater 
likelihood  of  "winners."  It  is  easier  to  pare  down  a  long  list  than 
to  puff  up  a  short  list. 

4.  COMBINATION  AND  IMPROVEMENT  ARE  SOUGHT  -  In  addition  to  contri¬ 
buting  ideas  of  your  own,  members  should  try  to  combine  and  add  to 
other  ideas.  HITCHHIKING  is  called  for. 

OSBORN's  IDEA-SPURRING  CHECKLIST: 


PUT  TO  OTHER  USES?  In  what  other  ways  could  this  be  used?  What  else 
could  be  made  from  this? 

ADAPT?  What  is  like  this?  What  other  ideas  does  this  suggest?  Is 
there  something  similar  I  could  copy? 

MODIFY?  What  change  can  we  make?  color,  meaning,  motion,  sound, 
odor,  taste,  shape 

MAGNIFY?  What  to  add?  Can  it  be  stronger?  Bigger?  Longer?  Multi¬ 
ply?  Extra  value? 


MINIFY?  What  to  subtract?  What  if  it  were  smaller?  How  about  div¬ 
iding  it?  Slow  it  up?  Make  it  lighter?  Can  I  omit  it? 

SUBSTITUTE?  What  else  instead?  Who  else  Instead?  Could  it  be  an¬ 
other  place?  Time? 

REARRANGE?  How  else  can  this  be  arranged?  Order  changed?  Another 
layout?  Changing  pace?  Another  sequence? 

REVERSE?  Transpose  it?  What  are  the  opposites?  What  are  the  nega¬ 
tives?  Another  point  of  view? 

COMBINE?  How  about  an  alloy?  A  blend?  Combine  units?  Combine 
purposes?  What  about  and  ensemble?  An  assortment?  Combine  ideas? 
Other  materials  to  combine? 
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NOMINAL  GROUP  BRAINSTORMING  METHOD; 


This  method  emphasizes  private  generation  and  ranking  of  solution. 

It  enforces  procedure  for  presentation  of  ideas  and  clarification. 
Debate  and  discussion  are  discouraged.  Group  can  work  productively 
with  less  confusion  and  less  conforming. 

The  problem  is  presented  to  the  entire  group.  Each  person  writes 
down  his/her  ideas,  alternatives,  solutions  privately  without  dis¬ 
cussing  them.  The  ideas  are  recorded  in  a  "round  robin"  fashion  on 
a  flipchart  so  everyone  can  see  them.  No  evaluation  is  allowed  at 
this  time,  only  clarification  of  idea  presented.  Anyone  in  the  group 
may  ask  another  person  for  clarification.  The  entire  list  is  reviewed 
and  like  ideas  combined  to  avoid  overlap.  Each  person  ranks  solutions 
privately.  The  results  are  tallied  to  determine  relative  support  for 
each  solution.  The  ranking  is  shared  -  again  on  a  flipchart  -  and 
ranked  again  privately  until  a  consensus  is  reached. 

Implementation  -  Goal  statement  - 

1.  Who  - 

2.  Will  do  what  -  other  objectives 

3.  Under  what  conditions 

4.  To  what  degree  of  success  (criteria).  Checkpoints  along  the  way. 

This  technique  allows  for  task,  social  and  emotional  involvement  in 
a  group. 


BLOCKS  OR  HOLDING  PATTERNS  TO  IDEA  GENERATION; 


PERCEPTUAL  BLOCKS  (occur  especially  when  problem  is  first  perceived) 

Difficulty  in  isoloating  the  problem  (can't  separate  object  from 
field) 

Difficulty  in  narrowing  the  problem  to  much  (paying  little  at¬ 
tention  to  the  environment) 

Inability  to  define  terms  or  isolate  attributes 
Failure  to  use  all  of  the  senses  in  observing 
Difficulty  in  seeing  remote  relationships 
Difficulty  in  not  Investigating  the  "obvious" 

Difficulty  arising  from  not  recording  "trivia" 

Failure  to  distinguish  between  cause  and  effect 
Inability  to  view  problems  from  various  viewpoints 
Seeing  what  you  expect  to  see 
Stereotyped  views 
Premature  labelling 

CULTURAL  BLOCKS  (acquired  by  exposure  to  a  given  set  of  cultural 
patterns) 

Desire  to  conform  to  an  accepted  pattern 

Must  be  practical  and  economical  above  all  things  so  that  judg¬ 
ment  comes  into  play  to  early 
Not  polite  to  be  too  inquisitive  and  not  wise  to  doubt 
Overemphasis  on  competition  or  on  cooperation 
Too  much  faith  in  statistics 
Too  much  faith  in  reason  and  logic 
Tradition  is  preferable  to  change 

Any  problem  can  be  solved  by  scientific  thinking  and  lots  of 
money 
Taboos 

EMOTIONAL  BLOCKS  (color  and  limit  how  we  see  and  how  we  think  about 
a  problem) 

Lack  of  challenge  -  problem  failure  to  engage  our  interest 
Excessive  zeal  -  over  motivation  to  succeed  quickly,  can  only 
see  one  direction 

Fear  to  make  a  mistake,  to  fail,  to  risk 

Prefer  to  judge  ideas,  rather  than  to  generate  them 

Cannot  relax,  incubate,  "sleep  on  it" 

Difficulty  in  rejecting  a  workable  solution  and  searching  for  a 
better  one 

Fear  of  supervisors  and  distrust  of  subordinates/colleagues 
Refusal  to  take  detour  in  reaching  a  goal 
Diffuculty  in  changing  set  (no  flexibility) 

Lack  of  dirve  in  carrying  problem  through  to  completion,  testing 
i  t  out 
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TEAM  BUILDING  -  GROUP  DYNAMICS 


Sometimes  it  seems  the  only  thing  we  do  is  attend  meetings.  Seldom  is 
any  task  or  project  solely  an  individual  one.  Meetings,  committees 
task  force  efforts,  team  efforst  all  require  a  high  order  of  skills 
to  ensure  that  such  group  expenditure  of  time  is  productive  and 
worthwhile.  Coordinating  efforts,  clarifying  responsibilities ,  as¬ 
signing  tasks,  making  progress  reports,  combining  needed  expertise, 
presenting  a  team’s  completed  work  for  approval  and  implementation 
are  several  of  the  more  important  group  tasks  we  are  constantly  in¬ 
volved  in. 

In  a  team  setting  all  of  the  different  understandings  and  perceptions 
of  each  individual  present  add  a  futher  diliemma.  The  leader,  as  well 
as  each  participant,  needs  to  be  aware  of  the  impact  of  individual 
differences  to  help  cope  with  one's  own  and  others'  likely  "hidden 
agendas."  Each  person  on  a  team  has  a  responsibility  to  help  faci¬ 
litate  the  team's  effort;  this  requires  awareness  and  attention  to 
group  proces  as  well  as  to  the  content  of  topics  discussed. 

Reaching  clarity  of  understanding  and  consensus  in  a  group  requires 
a  set  of  particular  skills  -  not  always  easily  understood: 

-  Establishing  a  climate  of  free  expression 

-  Acceptance  and  encouragement  of  differences  to  facilitate 
exploration 

-  Means  to  handle  conflict  and  lower  anxiety 

-  Expressing  consensus  and  gaining  agreement 

-  Moving  forward  to  further  concerns 

These  skills  can  be  improved  by  recognizing  and  acting  upon  the  fact 
that  every  group  has  two  functions:  1)  TASK  FUNCTIONS  and  2)  SOCIAL 
FUNCTIONS.  The  purpose  of  the  TASK  FUNCTIONS  is  to  keep  the  group 
working  on  the  task  at  hand  -  getting  the  work  done.  The  purpose  of 
the  SOCIAL  FUNCTIONS  is  to  maintain  constructive  group  relations  among 
the  members  and  to  keep  diverse  individuals  working  together  as  a 
team.  This  means  dealing  with  individual  and  group  feelings  and  at¬ 
titudes  which  may  prevent  the  progress  of  the  group  towards  its  goal. 
There  are  certain  TASK  FUNCTIONS  and  SOCIAL  FUNCTIONS  in  every  group 

-  these  are  explained  below: 

TASK  FUNCTIONS: 

-  INITIATING:  Proposing  tasks  or  goals,  defining  the  team  prob¬ 
lem,  suggesting  a  procedure  for  solving  the  problem 
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-  INFORMATION  SEEKING:  Requesting  facts,  seeking  relevant  in¬ 
formation  about  team  concern,  asking  for  ideas  or  suggestions 


-  CLARIFYING:  Elaborating,  Interpreting,  or  reflecting  ideas 
and  suggestions;  clearing  up  confusions;  indicating  alterna¬ 
tives  and  issues  before  the  team 

-  SUMMARIZING:  pulling  together  related  ideas,  restating  sug¬ 
gestions  after  the  team  has  discussed  them,  offering  a  con¬ 
clusion  for  the  team  to  accept  or  reject. 

SOCIAL  FUNCTIONS: 

-  ENCOURAGING:  Being  friendly  and  responsive  to  others;  ac¬ 
cepting  other  and  their  contributions 

-  EXPRESSING  GROUP  FEELINGS:  Sensing  the  feelings,  moods,  and 
relationships  within  the  team;  sharing  one's  own  feelings  with 
others 

-  HARMONIZING:  Attempting  to  reconcile  disagreements,  reducing 
tension,  getting  people  to  explore  their  differences 

-  MODIFYING:  When  one's  own  idea  or  status  is  involved  in  a  con¬ 
flict,  offering  to  modify  one's  own  position;  admitting  error; 
facilitating  the  participation  of  others,  suggesting  procedures 
for  sharing  opportunity  to  discuss  team's  problems 

-  EVALUATING:  Evaluating  team  functioning  and  production;  ex¬ 
pressing  standards  for  team  to  achieve,  measuring  results 
and  evaluating  degree  of  team  commitment. 

COHESIVENESS  -  THE  KEY  TO  SUCCESSFUL  TEAM  WORK 


Cohesiveness  refers  to  the  ability  of  the  team  to  stick  together.  Co¬ 
hesiveness  encourages  productivity,  morale,  and  communication.  Teams 
with  high  team  loyalty  have  greater  productivity,  higher  morale,  and 
better  communication  than  teams  with  little  cohesiveness. 

-  PRODUCTIVITY:  Cohesive  productive  teams  do  more  work  because 
members  take  the  initiative  and  help  one  another.  They  dis¬ 
tribute  the  work  load  -  take  up  the  slack  in  times  of  stress. 

-  MORALE:  Morale  of  the  team  members  is  closely  tied  to  cohe¬ 
siveness.  If  the  team  is  important  to  them,  people  pay  at¬ 
tention  to  its  problems  -  will  spend  time  an  effort  in  behalf 
of  the  team,  and  "glory"  in  its  successes. 
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-  COMMUNICATION:  Cohesiveoess  encourages  disagreements  and 
questioning  -  both  are  necessary  to  communication.  Members 
of  a  highly  cohesive  team  disagree  among  themselves.  Cannot 
stand  by  and  watch  others  do  a  shoddy  job  -  their  team  Is  at 
stake. 

The  symptoms  of  low  cohesiveness  -  teams  have  meetings  which  are 
quiet,  polite,  boring  and  apathetic.  People  seldom  disagree;  there 
is  little  give  and  take  discussion.  Important  decisions  are  handled 
quickly,  with  little  comment. 

The  symptoms  of  high  cohesiveness  -  team  meeting  tend  to  be  noisy, 
full  of  humor,  disagreement,  personal  byplay  and  some  argument.  Pew 
important  questions  are  raised  without  a  thorough  airing.  Discussion 
may  well  continue  after  the  meeting  is  over. 

INFORMATION  ON  TEAMS 

A  task  oriented  small  team  is  composed  of  three  or  more  people  working 
together  to  do  a  clearly  specified  job.  Research  in  small  group  work 
indicates  that  five  is  an  excellent  number  for  a  team  working  on  prob¬ 
lems.  Sever  or  nine  are  workable.  Teams  composed  of  an  even  number 
of  people  are  not  as  efficient  as  groups  totaling  an  odd  number.  In 
groups  of  five  or  less,  all  participants  speak  to  one  another,  even 
those  who  speak  very  little.  In  groups  of  seven  or  more,  the  quiet 
members  cease  to  talk  to  one  another  and  talk  only  to  the  top  leaders. 
As  groups  get  even  larger,  talk  centralizes  around  only  a  few  people. 
Group  interaction  falls  off.  As  the  group  gets  larger,  we  tend  to 
form  small  teams  (cliques)  within  the  larger  team. 

One  of  the  first  questions  most  people  in  the  new  work  group  ask  is: 
How  do  1  relate  to  these  people?  A  member's  role  is  worked  out 
jointly  by  the  person  and  the  team.  One  of  the  most  important  fea¬ 
tures  of  group  dynamics  is  the  power  of  nonverbal  and  verbal  communi¬ 
cation  to  get  people  to  act  as  others  in  the  group  do.  Every  new 
team  must  go  through  a  "tension"  period  during  which  roles  are  tested 
-  where  am  I  on  this  team? 

LEADERSHIP 

In  his  role  behavior  a  leader  uses  three  different  skills  -  TECHNICAL, 
HUMAN  and  CONCEPTUAL.  Though  they  Interrelated  in  practice,  they  can 
be  considered  separately. 

-  TECHNICAL  skill  refers  to  a  person's  knowledge  of,  an  pro¬ 
ficiency  in,  any  type  of  process  or  technique.  I.E.,  skills 
learned  by  engineers,  accountants,  etc,  in  the  practice  of 
their  specialties.  This  skill  is  the  distinguishing  feature 
of  job  performance  at  the  operating  level;  but  as  employees 
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are  proaoted  co  leadership  responsibilities,  their  technical 
skills  become  proportionately  less  Important*  They  increas¬ 
ingly  depend  on  the  technical  skills  of  their  subordinates. 

-  HUMAN  skill  is  the  ability  to  interact  effectively  with  people 
and  to  build  teamwork.  No  leader  at  any  organizational  level 
escapes  the  requirement  for  effective  human  skill.  It  is  a 
major  part  of  his  role  behavior. 

-  CONCEPTUAL  skill  becomes  Increasingly  important  in  higher 
managerial/leadership  roles,  because  these  leaders  are  deal¬ 
ing  more  with  long  range  plans,  broad  relationships,  and  other 
abstractions.  Conceptual  skills  deal  with  ideas,  while  human 
skill  concerns  people,  and  technical  skill  is  with  things. 
Conceptual  skill  enables  a  manager  to  deal  successfully  with 
abstractions,  to  set  up  models  and  to  devise  plans.  It  helps 
him  to  see  relationships  between  groups,  both  within  and  with¬ 
out  his  organization. 

Different  types  of  functions  and  different  levels  of  leadership  re¬ 
quire  different  mixes  of  skills.  A  further  breakdown  in  leadership 
skills: 

-  Ability  to  state  issues  in  such  a  way  that  group  does  not  be¬ 

come  defensive 

-  Ability  to  supply  essential  facts 

-  Ability  to  draw  people  out  so  that  members  will  participate 

-  Ability  to  restate  accurately  ideas  and  feelings  expressed 

-  Ability  to  wait  out  pauses 

-  Ability  to  ask  questions  -  stimulate  problem  solving  behavior 

-  Ability  to  summarize  -  more  it  along 

-  Ability  to  follow  through  on  commitments,  responsibllites  etc. 
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ANALYSIS 


NONE  _  REQUIRED  (Check  One)  Concluucm: 


NONE  _  REQUIRED  (Check  One)  Conclusion 


ANALYSIS  CHART 


Date :  Rev.  No. :  ROOT  CAUSE  ANALYSIS  CHART 

Faifara  Indication:  Cauee  ProUURte  E*ti»atet 


NONE  _  REQUIRED  (Check  One)  Conehiwon: 


ANALYSIS  CHART 


NONE  _  REQUIRED  (Check  One)  CoocI 


CAUSE  ANALYSIS  CHART 


ANALYSIS  CHART 


NONE  _  REQUIRED  (Check  One)  ConeluMon 


CAUSE  ANALYSIS  CHART 


REQUIRED 
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A  FAULT  OR  EVENT  CAUSED  BY  A  COMBINATION  Oh 
CONTRIBUTING  EVENTS. 

R 


OA  FAULT  OR  EVENT  CAUSED  BY  A  COMPONENT 

SUB-ASSEMBLY  FOR  WHICH  A  PROBABILITY  CAN 
BE  ASSIGNED.  ELIPSES  ARE  FREQUENTLY  USED 
AS  AN  ALTERNATE  TO  CIRCLES  FOR  EASIER 
TYPING. 


AND  GATE,  THE  OUTPUT  EXISTS  ONLY  IF  ALL  THE 
INPUTS  ARE  PRESENT  SIMULTANEOUSLY. 


OR  GATE,  THE  OUTPUT  EXISTS  IF  ANY  (OR  ANY 
COMBINATION)  OF  THE  INPUTS  ARE  PRESENT. 


AN  EVENT  WHICH  IS  CONSIDERED  TO  BE  A  NORMAL 
EVENT . 


OA  FAULT  THAT  IS  NOT  DEVELOPED  FURTHER  DUE  TO 
LACK  OF  INFORMATION  OR  IMPORTANCE. 


INHIBIT  GATE,  ALLOWS  APPLICATION  OF  A 
RESTRICTION  OR  CONDITIONAL  EVENT. 


(  )  INDICATES  RESTRICTIONS  OR  CONDITIONS. 


•  ' 


USED  AS  A  CONNECTING  SYMBOL  FOR  A  SIMILAR 
CONDITION  AT  ANOTHER  PART  OF  THE  TREE. 


FAULT  TREE  SYMBOLS 

*1 


TOY  LOGIC 


FLASHLIGHT  LOGIC 
DIAGRAM 


LOGIC  TREE  INDICATING  CAUSES  OF  BATTERY  FAILURE 


PLUGGED 
RELIEF  VALVE 


logic  diagrams- 


JJECT.lf  *| 

ccn  cmt 
3  MUZXlS  k 


30MM  Bore  Event 
Logic  Diagram 
Page  5  of  5 


UNDERSI2E 


FLASHLIGHT  WON*T  LIGHT 


CASE  STUDY  #2 


CAR  STARTING  PROBLEM  - 


1973  Chevrolet  -  80,000  miles  -  side  mount  battery  terminal 
Visual  evidence  present  - 

-  Car  driven  predominantly  in  city,  short  trips 

-  Hole  in  top  surface  of  battery  case  adjacent  to  positive  terminal 

-  Clear  liquid  oozing  out  of  hole  in  battery 

-  Intermittent  starting  1-3  tries 

-  Once  started,  car  runs  normal 

-  Car  jump-started  3  times  in  a  24-hr.  period,  continues  to  run 
until  ignition  is  turned  off 

-  Battery  label  sticker  on  top  of  battery  charred  entire  length 

-  Car  started  each  time  jumped  -  $6.00,  average  time  -  I  hour 

-  Battery  replaced  one  year  ago 

-  Generator  discharge  light  does  not  light  up 

-  Flashers  work;  radio,  air  conditioning  works 

-  Two  days  pr ior — overheat ing  problem  -  temp  light  lighted  when  car  idled 
in  traffic 

-  Never  replaced  alternator 


CASE  NOTES 


General  condition  of  engine  compartment  dirty,  greasy  — 

need  for  maintenance 

Key  difficult  to  insert  into  ignition 

Ignition  lock  has  excessive  play 

Excessive  rust  in  areas  of  battery/clamps 

Electrical  system  is  negative  ground 


indicates 


TEAM  ASSIGNMENT 

To  prepare  a  logic  diagram  of  ait  possible  systems,  sub-stems  and/or 
components  which  could  be  root  cause  of  this  problem. 

Facts  which  are  described  in  the  case  study  should  be  considered  as 
minimum  information.  Use  your  past  experience,  knowledge  of  auto  operation 
to  include  as  many  relevant  areas  as  possible. 

Assume  you  can  consult  with  driver  by  phone  to  collect  additional 
information  -  what  questions  would  you  ask? 


